Architekturstandards mit .NET-Framework durchsetzen

So empfängt eine ASP.NET-Anwendung zum Beispiel anwendungsspezifische Einstellungen von einer web.config-Datei. Falls diese Datei unverändert bleibt, wird sie die Daten von der machine.config-Datei übernehmen, die wiederum die Standardeinstellungen für alle Anwendungen auf diesem System kontrolliert.

Standardmäßig kann der Entwickler die Art und Weise, wie Anwendungen mit ASP.NET interagieren, anpassen, indem er die Einstellungen in der web.config-Datei ändert, die sich im Stammverzeichnis der jeweiligen Anwendung befindet. Will man zum Beispiel sicherstellen, dass jede für Benutzer verfügbare Web-Anwendung auf einen gemeinsam benutzten Statusserver zugreifen kann, konfiguriert man hierzu einfach die machine.config-Dateien auf jedem Server in der Rechnerfarm, so dass das sessionState-Modus-Attribut auf StateServer anstelle der Standardeinstellung InProc gesetzt ist.

Dies mag einen Segen für den Entwickler darstellen, ist aber ein potentieller Albtraum für den Systemarchitekten. Betrachten wir folgendes Beispiel zur Status-Verhaltung: Solange der Anwendungsentwickler die vom neuen Visual Studio-Assistenten generierte Standard-web.config-Datei nicht verändert, wird die lokale web.config-Datei immer auf InProc eingestellt sein. Sobald die Anwendung auf der Serverfarm eingesetzt wird, wird sie nicht den Statusserver nutzen, sondern jeder Server wird seinen Status selber speichern. Um sicherzustellen, dass vorher festgelegte Produktionsstandards von allen Applikationen eingehalten werden, bietet das .NET-Framework zwei Mechanismen, um die gewünschten machine.config-Einstellungen zu erzwingen.